IBIS Macromodel Task Group

Meeting date: 15 July 2014

Members (asterisk for those attending):
Agilent:                    * Fangyi Rao
                            * Radek Biernacki
Altera:                     * David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                            * Ken Willis
Ericsson:                     Anders Ekholm
Intel:                        Michael Mirmak
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

-------------
New Discussion:


Draft BIRD for matrix value:

- Randy showed a draft BIRD.
- Randy: This came from a model with a negative resistance that IBISCHK did not catch.
  - Adding a requirement to the specification would drive a new IBISCHK check for that.
  - Three statements are added.
  - Should it be "positive" or "non-negative"?
- Radek: "non-negative" is good.
- Mike: Is zero allowed?
- Arpad: Yes.
- Randy: Vladimir at Mentor gave some feedback.
  - He suggested other checks that might be done.
  - Diagonal dominance for C.
- Radek: There are checks like passivity that are beyond what we should do.
- Bob: The intent is to do only simple checks.
- Arpad: Checking for positive off diagonals is not a hard test.
  - Where do we draw the line?
- Walter: We might want a best practices white paper.
- Bob: An analysis might blow up with bad data.
- Arpad: Do we have to check all of these rules?
- Bob: Maybe not.
- Radek: Maybe EDA tools should do this.
- Mike: It is fair to have rules that are always true, should never be violated.
  - Is the phrase "will be" correct for this?
- Radek: It should be "shall be".


Back-channel:

- Arpad showed a single slide.
- Arpad: We have reached no consensus.
  - Complete optimization should not be part of IBIS.
  - Any vendor can handle that without IBIS changes.
  - Both proposals rely on the RX to control optimization.
  - SiSoft would support legacy TX models.
  - BIRD 147 could be extended to allow the EDA tool to act on behalf of the TX.
- Ambrish: It is not true that we look at only tap settings.
  - The EDA tool can't help legacy models in that case.
- Arpad: Could you list some parameters?
- Ambrish: Jitter compensation, for example.
- Ken: We should not expand the scope of BIRD 147.
  - We should finish the BIRD by the end of the month.

- Radek: The dependence on BIRD 128 must be discussed here.
  - BIRD 147 is not sufficient and potentially dangerous.
  - There are memory allocation issues.
  - We should extend the API.
  - There should be no issue if we excluded legacy models.
- Ken: I'm not familiar with BIRD 128
- Arpad: AMI_GetWave does not allow InOut parameters.
- Ken: I think BIRD 147 has something about that, does it reference BIRD 128?
- Ambrish: Yes.
- Radek: Memory allocation protocol must be specified.
- Arpad: I would like GetWave to have a consistent footprint.
- Radek: It could be AMI_GetWave or BCI_GetWave.
  - New DLLs will be needed, there should be no problem.
- Ambrish: The current approach has been tried and it works.
- Radek: We don't want to find out years from now that something is wrong.
- Arpad: We should discuss BIRD 128.
- Radek: We could describe a new API in BIRD 147.
- Ambrish: What we have is sufficient, adding more might be redundant.
- Arpad: A future feature that needs InOut would have to use BCI_GetWave but that's awkward.
- Ambrish: GetWave can do it.
- Ambrish: With overloading we can have the same function with different arguments.
- Radek: The name is OK, but this is an extended API.
- Arpad: Should BIRD 128 language be folded into BIRD 147?
- Radek: Yes.
- Ambrish: Is the rest of BIRD 147 settled?
- Arpad: We can add BIRD 128 content to BIRD 147 and vote down BIRD 128.
- Radek: I still want to see a proper API without using AMI_parameters_out.
- Arpad: Yes, not exactly what BIRD 128 proposes.
- Mike: Something in the AMI file has to indicate AMI_GetWave has a different call signature.
- Ambrish: It would be good if Radek could help.
- Radek: I will try.

Agenda list:

- Mike: Can we drop item 15?
- Arpad: It has been discussed in other circles.
  - Greg Edlund has not attended these meetings for some time.

- Walter: There was an email thread about NAs for min and max data.
  - It might be best to have another place to address issues like that.
- Arpad: The spec seems to say in some places to use typ for NA
  - It does not say that for V-T and I-V tables though.
  - Some combinations can make no mathematical sense.
  - The data that do have mathematical relationships might need some rules.
- Walter: In some tables only some values are missing and it's OK to interpolate for those.
  - The problem is when an entire column is missing.
- Mike: IBISCHK can issue Notes, Cautions, and Warnings for things not in the spec.
- Arpad: New tables like ISSO have some conditions that are impossible.
- Mike: Checks like the V-T to Ramp checks would be OK
  - But finding one non-NA value in a column should not start a check
- Arpad: Some things can be synthesized, but it has limits.
- Radek: The rules are for individual pieces of data without discussion of interdependencies
  - Establishing those would not be backward compatible.
  - Some checks could provide insight into the missing data.
  - We have many IBIS files out there.
- Bob: This is a day one mistake
  - we should have required all values in a column to be filled in or none.
  - We can only make a strong recommendation.
- Randy: It's a little scary that someone could simulate with a model that is missing data.
  - There should be warnings or errors for this.

-------------
Next meeting: 22 Jul 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
